UMTS (Universal Mobile Telecommunications System) is the 3G (3rd Generation) mobile communication system standardised by 3GPP (3rd Generation Partnership Project).
LTE—Long Term Evolution
In order to be prepared for further increasing user demands and to be competitive against new radio access technologies the 3GPP launched a study item “Evolved UTRA and UTRAN” better known as “Long Term Evolution (LTE)”. The study investigated means of achieving major leaps in performance in order to improve service provisioning and to reduce user and operator costs. Out of that and because interworking with other radio access technologies should be possible, the need arose for a new evolved Packet Core Network.
An exemplary representation of the evolved system architecture is given in FIG. 1. The E-UTRAN consists of evolved Node Bs (eNB or eNodeB), providing the E-UTRA user plane (PDCP/RLC/MAC/PHY) and control plane (RRC) protocol terminations towards the mobile node (also denoted UE or MN).
The eNB hosts the Physical (PHY), Medium Access Control (MAC), Radio Link Control (RLC) and Packet Data Control Protocol (PDCP) layers that include the functionality of user-plane header-compression and encryption. It also offers Radio Resource Control (RRC) functionality corresponding to the control plane. Further, it performs many functions including radio resource management, admission control, scheduling, enforcement of negotiated UL-QoS (Quality of Service), cell information broadcast, ciphering/deciphering of user and control plane data, and compression/decompression of DL/UL user plane packet headers. The eNBs are also connected by means of the S1 interface to the EPC (Evolved Packet Core), more specifically to the MME (Mobility Management Entity) by means of the S1-MME, and to the Serving Gateway (S-GW) by means of the S1-U.
The S-GW routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNB handovers and as the anchor for mobility between LTE and other 3GPP technologies (terminating S4 interface and relaying the traffic between 2G/3G systems and Packet Data Network Gateway). For idle state UEs, the S-GW terminates the DL data path and triggers paging when DL data arrives for the UE. It manages and stores UE contexts, e.g. parameters of the IP bearer service, network internal routing information. It also performs replication of the user traffic in case of lawful interception.
The MME is the key control-node for the LTE access-network. It is responsible for idle mode UE tracking and the paging procedure including retransmissions. It is involved in the bearer activation/deactivation process and is also responsible for choosing the S-GW for a UE at the initial attach and at time of intra-LTE handover involving Core Network (CN) node relocation. It is responsible for authenticating the user (by interacting with the Home Subscriber Server, HSS). It checks the authorization of the UE to camp on the service provider's Public Land Mobile Network (PLMN) and enforces UE roaming restrictions. The MME is the termination point in the network for ciphering/integrity protection for NAS signaling and handles the security key management. The MME also provides the control plane function for mobility between LTE and 2G/3G access networks with the S3 interface terminating at the MME from the SGSN (Serving GPRS Support Node). The MME also terminates the S6a interface towards the home HSS for roaming UEs.
The Packet Data Network Gateway (PDN-GW) provides connectivity for the UE to external packet data networks by being the point of exit and entry of traffic for the UE. A UE may have simultaneous connectivity with more than one PDN-GW for accessing multiple PDNs. The PDN-GW performs policy enforcement, packet filtering for each user, charging support, lawful interception and packet screening. Another key role of the PDN-GW is to act as the anchor for mobility between 3GPP and non-3GPP technologies.
To summarize the above, in order to support the new E-UTRAN access, the new 3GPP Core Network is mainly separated into three logical entities. At first, in the user plane the PDN-GW is the gateway to the external networks and the global mobility anchor for mobility between 3GPP and non-3GPP access technologies (like CDMA2000, WiMAX or WiFi). Second, another user plane entity, the Serving Gateway, is the mobility anchor for mobility between 3GPP accesses (E-UTRAN, UTRAN, GERAN). Third, a Mobility Management Entity is the control plane entity responsible for the mobility management of mobile terminals (also referred to in the following as UEs or MNs) moving between different EUTRAN base stations (eNodeBs) and also responsible for the session management.
As described above, the MME is responsible for mobility management and session management. For each mobile terminal attached to an MME, specific mobility management and evolved packet system context information is stored in the MME. These contexts comprise e.g. the mobility state, the temporary identity, the current Tracking Area List, last known cell, authentication vectors, access restrictions, subscribed QoS profile, subscribed charging characteristics and for each active PDN connection the APN (Access Point Name) in use, IPv4/IPv6 addresses, PDN-GW address for control plane and also information for each EPS (Evolved Packet System) bearer within the PDN connection, as for example EPS bearer QoS profile, EPS bearer charging characteristics.
The mobility management within the 3GPP system is network controlled, and two protocol variants are standardised for the interface between the PDN-GW and the S-GW. One is based on GTP (GPRS Tunneling Protocol), the protocol used in the legacy GPRS (General Packet Radio Service) system, and the other one is Proxy Mobile IPv6 (PMIPv6), developed in the IETF (Internet Engineering Task Force). For interworking with non-3GPP accesses, the mobile terminal can be connected to the Core Network, i.e. the PDN-GW, via PMIPv6 as well, in case the non-3GPP access supports PMIPv6. Alternatively, if the mobile terminal does not support inter-access handover with PMIPv6 or if the non-3GPP access does not support PMIPv6, the mobile terminal can be connected to the Core Network via Client Mobile IP versions, i.e. Mobile IPv4 Foreign Agent Mode (MIP4FA) or Dual Stack Mobile IPv6 (DSMIPv6).
Machine to Machine
The current mobile networks are optimally designed for Human-to-Human communications, but are less optimal for M2M (Machine-2-Machine) applications, which according to 3GPP is also termed MTC (Machine-Type-Communication).
M2M Communication can be seen as a form of data communication between entities that do not necessarily need human interaction. It is different to current communication models as it involves:                new or different market scenarios        lower costs and effort        a potentially very large number of communicating terminals        to a large extent little traffic per terminal        
Some MTC applications are for example:                Security (e.g. Alarm Systems, Backup for landline, Access Control, Car/Driver security)        Tracking & Tracing (e.g. Fleet Management, Order Management, Pay as you drive, Road Tolling, Traffic information)        Payment (Point of Sales, Vending machines, Loyalty Concepts, Gaming machines)        Health (Monitoring vital signs, Remote diagnostics, Web Access Telemedicine point)        Remote Maintenance/Control (Sensors, Lighting, Pumps, Valves, Elevator control)        Metering (e.g. Power, Gas, Water, Heating, Grid Control)        
A study item on M2M communications (3GPP TR 22.868) was completed in 2007; however, no subsequent normative specification has been published. For Rel-10 and beyond, 3GPP intends to take the results on network improvements from the study item forward into a specification phase and address the architectural impacts and security aspects to support MTC scenarios and applications. As such, 3GPP has defined a work item on Network Improvements for Machine-Type Communication (NIMTC). The following goals and objectives are described in the work item:                Provide network operators with lower operational costs when offering machine-type communication services        Reduce the impact and effort of handling large machine-type communication groups        Optimize network operations to minimize impact on device battery power usage        Stimulate new machine-type communication applications by enabling operators to offer services tailored to machine-type communication requirements        
Depending on the kind of application, a very large number of MTC devices can be deployed in some areas, e.g. smart meters in an urban area. In this case it may happen that all the MTC devices establish a connection to the network at the same time, thus causing a signaling peak and congestion in the network. This may be the case for example if                there is a malfunctioning in the MTC application and/or MTC Server        an external event (end of power outage) triggers MTC devices to attach/connect        recurring applications are synchronized to the exact (half/quarter) hour        
If the number of connection establishment requests is getting too high, the SGSN/MME can reject some of the connection establishment requests. However, the congestion is only resolved in the Core Network but not in the Radio Access Network. Thus, in case many MTC devices are in the same cell and are causing a signalling peak there is also congestion in the Radio Access. In addition, the Core Network entities may be already overloaded because of a mass of concurrent transmissions/attachments at once. Therefore, the rejection by the SGSN/MME may be too late.
FIG. 2 illustrates the number of MTC devices connecting to the network over time. As can be seen, the peak event triggers the connection establishment of the MTC devices which rapidly leads to a congestion of the system.
In the prior art there are three different kinds of solutions how to reduce or prevent signalling congestion or overload in the network:                Rejecting connection requests by the SGSN/MME: this solution is based on the rejection of NAS signaling requests (attach request or TAU request or Service Requests) sent from the MTC Devices. The SGSN/MME can decide to reject signaling requests for MTC Devices attached to a particular APN or belonging to a particular MTC Group. Further, to avoid an MTC Device from re-initiating a connection request or attach request immediately after a reject to an earlier request, the SGSN/MME can provide a back-off time to the MTC Device in the reject message. The problems with this approach are:                    only congestion in the Core Network (SGSN/MME and GGSN/PGW) is resolved, but not in the Radio Access because the MTC devices continue to establish RRC connections in order to send the NAS signalling requests to the SGSN/MME.            also mass concurrent transmission/attachments may overload Core Network entities at once, so that rejection may not work and is already too late as well.                        Rejecting connection requests by the RAN: it is proposed that the MTC Devices can send a “low-priority indication” in the RRCConnectionRequest message. The NB/eNB can be configured to reject low priority signalling requests by the MTC Devices, i.e. if the NB/eNB is aware about a congestion situation in the core network (CN) or RAN network. Further, the eNB can inform the MME (via S1-AP) about the low-priority of the UE, so that the SGSN/MME can also decide to reject the NAS signalling request from the MTC Device, if there is a congestion at the Core Network. Additionally, the eNB can provide an extended back-off timer to inform the MTC Devices when they may re-initiate the signalling. The problems with this approach are:                    The MTC Devices already competed for RACH channel to send RRCConnectionRequest, i.e. the MTC has already used contention-based preambles.                        Baring the access for the MTC Devices including baring information in the SIB2: the access class baring (ACB) functionality has been already specified in previous releases of 3GPP. The ACB can be applied to UEs belonging to a particular access class. This solution extends the granularity for baring to be 1) All MTC Devices, 2) particular MTC Group, 3) per APN, 4) per PLMN. The problems with this approach are:                    Baring is a slow process (in worst case it can take ˜20 sec due to the maximum system information modification period).            Baring in the whole PLMN coverage is not desired.                        
Paging
When a UE is in IDLE state and camps on an eNB cell, the UE is synchronized with the cell in order to be able to read paging information. The paging is a general procedure for seeking the UE within an amount of cells, where the UE stays in IDLE state. When a UE receives a paging message/signal, the UE transfers from IDLE to CONNECTED state and establishes an RRC connection with the eNB where the UE is camped in IDLE mode.
The MME is informed by the UE's P/SGW that packets should be delivered. The MME sends a paging message (PM) to all eNBs being part of the so called tracking area where the UE can move without the Tracking Area Update (TAU) procedure (except the periodic TAU procedure). The PM from the MME to the eNB contains amongst other the following information:                UE_ID Index Value: known as UE_ID, which is calculated by (IMSI mod 1024). Correspondingly, the UE_ID may have values in the range of [0, 1 . . . 1023].        UE Paging Identity: can be the IMSI (as stored on the SIM card) or the SAE-Temporary Mobile subscriber ID (S-TMSI) assigned to the UE during the attach procedure. The UE paging Identity is transmitted from the eNB to the UE in a paging message (PM) over the radio interface (i.e. Uu interface).        Paging DRX cycle: is the Discontinuous Reception (DRX) cycle configured in the UE (using NAS signalling) or the default DRX cycle broadcast in the System Information Block (SIB). The default DRX cycle is also known as Paging Cycle in the RadioResourceConfigCommon SIB. The UE may use discontinued reception in IDLE mode in order to reduce power consumption. The DRX cycle is a time interval between monitoring Paging Occurrences for a specific UE. The values of the default DRX/paging cycle broadcast in the SIB are 32, 64, 128 or 256 radio frames.        
Triggered by the PM from the MME, the eNB then broadcasts another PM over the radio interface in a defined paging occurrence. The calculations of the paging occurrence in the eNB and the UE are aligned so that they send/listen to the paging message in the same paging occurrence. The paging occurrence means in which radio frame (called paging frame, PF) and in which subframe (paging occasion) the paging message is sent. The paging frame number (PF#) is calculated according to the following formula:PF# mod T=(T div min(T,nB))*(UE—ID mod min(T,nB))where “T” is the DRX Cycle and “nB” is a SIB parameter.
The paging occasion has values in the range of [0, 1, . . . 9], as in LTE there are 10 subframes within one radio frame. The paging occasion number (also indicated by i_s below) is calculated according to the following formula:i—s=floor(UE—ID/min(T,nB)) mod (max(1,nB/T)).
If the UE is triggered to read the paging message and the paging message contains the UE's identity (UE paging identity is the UE's IMSI), then the UE is informed that data is waiting to be delivered and the UE transfers from IDLE to CONNECTED state, i.e. the UE initiates the RRC connection establishment procedure.
It should be noted that the abbreviation “PO” is used throughout the description, as paging occurrence or paging occasion. A paging occasion refers to the subframe having a number in the range of [0, 1 . . . 9] within a paging frame. Paging occurrence is a general term for the paging frame and the paging occasion, and refers to the location of the resources in the PDCCH (physical downlink control channel) monitored by the UE for paging messages.
A UE is paged by using the IMSI (or S-TMSI) of the UE as paging identity in the paging message send in the PDSCH (physical downlink shared channel). Therefore, for each UE a separate paging message has to be transmitted from the MME to the eNB(s), which has then to be broadcast from the corresponding eNB(s). This is reasonable because the incoming traffic (e.g. voice call or SMS) for the different UEs arrives separately and is not synchronized, so that the network pages the individual UEs separately as well.
However, MTC devices have traffic pattern and applications that are different from the usual UE. Thus, it is a realistic scenario where it would be advantageous that the network may want to trigger a group of MTC devices simultaneously. In a scenario in which a large number of MTC devices is deployed and is to be paged at generally the same time, this would cause a great amount of traffic because of the numerous paging messages transmitted in the core network and over the radio interface. Aggravating is the fact that each paging message transmitted over the radio interface by the eNB is retransmitted a couple of times, e.g. 3 times, thus generating even more traffic and wasting important radio resources.